In trying to test this locally, it looks like it might not have totally fixed it, but it could be getting overridden by the temporary fix the Vets.gov team put in for this issue. @rtluu can you provide a link to the fix from the Vets.gov side so I can test that interaction? Thanks!

hey @annekainicUSDS, the 4th chapter of this form on staging has the multiline checkbox implementation https://staging.vets.gov/education/gi-bill-school-feedback.

Sorry, I meant the lines of code that fixed this issue that were added to Vets.gov, @rtluu.

Ohh gotcha, @cehsu would you be able to point Anne towards the change that was made on vets-website?

Here is the multiline label implementation on Vets.gov, please let me know if anything else would be helpful.
https://github.com/department-of-veterans-affairs/vets-website/blob/5c13ca132cd7154a8ad90296e19a6934af815f8f/src/applications/edu-benefits/feedback-tool/helpers.js#L230

@cehsu @rtluu I'm confused about the latest information provided in this ticket. It seems like we're talking about two different cases of checkbox usage. In the original ticket for this issue, you included a screenshot of a page where the second set of checkboxes had extra spacing between them. You alluded to a temporary fix added on the Vets.gov side to remove this extra spacing until a permanent fix could be applied to USFS. When I navigate to that page and inspect those checkboxes, I see a style that adds margin-top: 0 to those checkboxes.

If that style is removed, I can see the extra space between the checkboxes. The style that should be adding the margin-top: 0 below is not being applied to the second set of checkboxes properly.

This first style seems like the one the Vets.gov team added to overwrite the issue. Is that correct? If so, could you please provide a link in the codebase to that style?

The additional comments in this PR that include a screenshot of checkboxes with italicized text beneath them and the link to the markdown implementation of those checkboxes seems unrelated to the original reason this issue was filed, but correct me if I'm wrong on that.

I rebased and force-pushed to ensure it won't try to put the built css file back when this is merged.

@rtluu @cehsu ping on this! Please see my latest comment for the information we're still looking for from you guys on this PR.

Thanks @annekainicUSDS, they are provided here.

@dmethvin-gov @cehsu @rtluu I've dug into this issue and PR quite a bit, and I think this particular fix is not the right solution for the problem. Here are the things I've learned:

• The CSS fix in this PR does not remove the margin between the checkboxes are intended. That's because it's targeting classes with a parent that has the class .schemaform-first-field, which is only wrapping the first checkbox in a list of checkboxes. Therefore the margin-top: 0 will not be applied to subsequent checkboxes.
• For the specific page in the feedback tool we've been looking at, there are 2 distinct groups of checkboxes. For some reason, the first group has the class .schemaform-first-field added at the top level of the markup (on the <fieldset/>), whereas the second group only has the .schemaform-first-field class added to the first checkbox in the group, which is why the CSS is not being applied properly. I think this class .schemaform-first-field, which is applied here, is only being applied to the top of the first group of checkboxes and not the second because it finds the first instance of .schemaform-field-template and just applies the class to that first instance.
• Regardless of the weird difference between the markup, we could add additional CSS to remove margin-top for all checkboxes, but this change will affect all checkbox groups built with USFS, and that would not be an appropriate change to make. We would want to evaluate how we want any checkbox to appear for any form generated by USFS before making that type of change.

If the Vets.gov team wants to collapse all margin between checkboxes, I believe that is a change they should keep on their side, because I don't think that's a change we want to implement for all checkbox groups in USFS.

In digging into this issue, I've discovered some inconsistencies across various form examples of how checkbox groups are rendered by USFS that I think may need investigation as a separate issue. But I think this PR solving this particular problem should be closed. Let me know if you have comments or additional feedback, otherwise I will close on Monday.

I'm fine with closing this, especially since I wasn't able to confirm the problem myself.

Thanks for looking into this @annekainicUSDS, that's a helpful assessment and a good plan for moving forward.